The invention relates generally to computer databases and more particularly, but not by way of limitation, to techniques for providing user access to database images.
Database information is typically used for many different purposes within a single organization. In many modern organizations, databases are used to store a businesses operational data. Such data may be used, for example, by order entry, payroll and invoicing applications. The same data may also be used by analysts looking for business trends, evidence of fraud and the like. In addition, information technology and product development personnel often use databases to develop, test and troubleshoot applications. Each class of user (e.g., accounting, order, product development and business analyst) has different requirements for the underlying data, requirements that are often not compatible with one another. For example, an analyst performing detailed trend analysis on product purchasing data may significantly impact the response time for an order entry application using the same underlying data. To mitigate the conflicts between various users or to limit access to the primary data, databases, or portions thereof, are often copied to another database.
In one prior art technique, data is copied from a source database (e.g., an order-entry database) to a target database. Probably the most common method used to copy data from one database to another is to unload the data from the source database and load it into the target database. Although straightforward, this method requires significant resources in terms of central processor unit time and input-output bandwidth on both the source and target database systems. In addition, copy operations typically read all of the source data, write all of the source data to one or more temporary files, read all of the data (again) from the temporary files and then write (again) all of the data to the new target database. Further, during the initial read operation, i.e., from the source database to the one or more temporary files, write-access to the source database is almost always blocked to ensure the unload operation produces a consistent copy.
In another prior art technique, the copy operation takes advantage of prior made “backup” copies or images of the source database. Often, backup copies are made (on regular intervals) that are initially only readable by the database system that created them. However, utility applications may be created that read a standard backup copy, and then translates and/or converts the data so that it may be written to (and subsequently accessed by users of) the new target database. One aspect of such utility applications is that they are also required to read and translate the source database's indexes (i.e., rebuild the indexes). These copy-from-backup techniques may also affect, or limit, the availability of the source data. For example, write-access to the source database is almost always blocked to ensure the copy operation produces a consistent copy. Alternatively, the copy operation may use the source databases log files to generate a consistent copy. A disadvantage of this approach, however, is that using log files to produce a consistent copy can require a significant amount of time and consume significant amounts of processor and input-output resources.
Referring to FIG. 1, in a typical environment source user 100 interacts with source database management system (DBMS) 105 to access (read and write) source database 110 retained in storage system 115. In the ordinary course of operations, image copies of source database 110 are often made for purposes of backup and/or disaster recovery. For example, image 120 represents an image copy of source database 110. A characteristic of image copies, such as image 120, is that they are replicas of their source database. This means that the schema (structure), data (content, including indexes) and internal source DBMS identifiers associated with source database 110 are replicated substantially identically in image 120. A consequence of this latter characteristic is that to avoid name-space conflicts, no DBMS other than source DBMS 105 can generally access image 120. Accordingly, if the data in image 120 is to be made available to target user 125 through target DBMS 130, its data must be extracted and copied 135 into a format compatible with the target DBMS, i.e., the data content of image 120 is copied into target database 140 as described above.
Thus, it would be beneficial to provide a mechanism to allow access to the data captured in image 120 without impacting the performance of source database 110 and without the need to extract and copy the data content of image 120 into a second (target) database.